|
|
| Author |
Thread Statistics | Show CCP posts - 8 post(s) |
Allen Ramses
Caldari
Typo Corp
   |
Posted - 2009.02.08 02:45:00 -
[1]
Target Name: N/A
IP: 87.237.38.200
Date/Time: 2/7/2009 6:28:53 PM to 2/7/2009 6:37:46 PM
Hop Sent Err PL% Min Max Avg Host Name / [IP]
...
8 213 0 0.0 16 89 23 xe-1-2-0.sjc10.ip.tiscali.net [213.200.80.165]
9 213 0 0.0 164 262 171 xe-1-0-0.lon20.ip.tiscali.net [89.149.186.81]
10 213 55 25.8 177 426 190 telecity-redbus-gw1.ip.tiscali.net [213.200.79.130]
11 213 0 0.0 164 315 170 mailtx.2zxr.com [217.20.44.10]
12 212 212 100.0 0 0 0 [-]
13 213 0 0.0 177 209 180 [87.237.38.200]
The above hop does not look healthy at all. Granted ICMP is at low priority, the inability for the host to provide a response to an ICMP query to that degree is an obvious indicator that it is overwhelmed with other operations.
____________________
CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
Allen Ramses
Caldari
Typo Corp
|
Posted - 2009.03.03 18:31:00 -
[2]
I did some research on the subject, and I found out a few things.
1. The IP with the DNS of mailtx.2zxr.com belongs to telecity group. It was formerly a mass email daemon provider. When telecity took it over as a routing IP, the master DNS providers apparently never updated their domain assignments.
2. Telecity hosts the backbone for several datacenters. Changing primary ISPs is not an option.
3. The place where all the packet data is caught up appears to be the gateways for telecity.
4. All of these gateways are located in the London Internet Exchange (LINX).
Following the above logic, there are two possible explanations. First possibility is that telecity routers or TQ's nodes have improperly configured packet sizes, causing packet fragmentation or packet shaping at the gateways. The second possibility is that there is a resource allocation or line quality problem between LINX and surrounding tier 1 networks.
____________________
CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
Allen Ramses
Caldari
Typo Corp
|
Posted - 2009.03.05 22:56:00 -
[3]
FFS.
The problem was NEVER telecity. The problem is the outlying gateways routing INTO telecity. I seriously doubt that the host of one of the largest datacenters is to blame when it's their ISPs that are losing packets.
Since Telecity re-routed all of their tables to try and eliminate any possible machines in their control, and the same problems persist, it places LINX as the most likely culprit.
____________________
CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
Allen Ramses
Caldari
Typo Corp
|
Posted - 2009.03.06 05:33:00 -
[4]
 Originally by: Cyclicus Remba
but at least the 10 hop is no longer a 100% wall of fail.
You do realize some routers are configured not to respond to ICMP packets, right?
Anyway, blame LINX.
____________________
CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
Allen Ramses
Caldari
Typo Corp
|
Posted - 2009.03.06 20:31:00 -
[5]
Originally by: Agent Unknown
Look at the lag spike from 13-17....~15 ms to almost 100 in one hop? That doesn't seem right. Looks like a backbone issue to me...
~15ms to almost 100 in one hop? That doesn't seem right. Looks like the route is taking an unexpected detour from New York to London. It's not like that kind of dist... Oh, wait.
____________________
CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
Allen Ramses
Caldari
Typo Corp
|
Posted - 2009.03.07 00:07:00 -
[6]
Edited by: Allen Ramses on 07/03/2009 00:08:57
Originally by: Miles Apart
As you can see, I am getting 100% loss from the 8th hop, the same that is supposedly causing problems.
So I wouldnt get too carried away with what you see from traceroute/PingPlotter....
Please don't use a router configured not to respond to ICMP as an argument to taking a very congested router (25% - 60% ICMP loss) with a grain of salt.
EDIT: What I am saying is a router ignoring ICMP is one thing, a router unable to process ICMP is something completely different.
____________________
CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
Allen Ramses
Caldari
Typo Corp
|
Posted - 2009.03.07 22:03:00 -
[7]
OpenDNS is exactly what the name implies. An Open Domain Name Service. Since domain resolution is only IP name assignment, it should not affect the route in any way.
Sorry, but this is snake oil. If you are no longer getting disconnects, this is not why.
____________________
CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
|
|
| |
|